This assertion now couples the public API to the private _DatabasePath implementation. If _DatabasePath is meant to be an internal compatibility shim, tests should validate the public contract instead (e.g., os.fspath(die.database_path) returns an existing directory, and it behaves like a PathLike) rather than asserting the internal type.

The assertion uses the same expression on both sides of the or ((db_path / dir_name).exists() or (db_path / dir_name).exists()), which makes the or redundant and suggests the test isn't checking what was intended. If the goal is to allow both layouts, consider checking the alternate location explicitly (e.g., nested db/), or just assert on the resolved path only.

__truediv__ returns a pathlib.Path instance here (return base_path), while other divisions return a _DatabasePath/PurePath. This inconsistent return type can surprise callers and makes path chaining behave differently depending on the segment. Prefer returning the same path type consistently (e.g., return a _DatabasePath pointing at the resolved base path) while still emitting the deprecation warning.

These multi-line scan_file calls are not formatted consistently with the rest of the file (missing trailing comma on the last argument, so Black would reformat it). Please add trailing commas so formatting is stable and consistent with existing calls above.

This install-time removal deletes ${CMAKE_INSTALL_PREFIX}/db if it exists. Even if this is intended for wheel staging, it is very broad and could remove an unrelated db directory when installing to a non-staging prefix. Consider narrowing the deletion by verifying the directory contains DIE signature markers (e.g., PE/) and/or removing only the exact path that die_library installs into, to reduce the risk of unintended data loss.

database_path used to be a pathlib.Path, but _DatabasePath currently subclasses pathlib.PurePosixPath, which is not a concrete filesystem path type and breaks isinstance(die.database_path, pathlib.Path) for existing callers. Consider instead subclassing the platform-specific concrete path type (e.g., type(pathlib.Path())) or making database_path a normal pathlib.Path and adding a separate helper/wrapper for the backward-compat resolution, so the public API type remains stable.

The docstring claims the fixed layout applies to "new versions (0.6.0+)", but this PR bumps the extension module to 0.5.1 and the packaging metadata appears to still be 0.5.x. Please align these version references (or remove explicit version numbers) so the documentation matches the actual release/versioning used by the package.

m.attr("__version__") is bumped to 0.5.1 here, but the build/package versions still appear to be 0.5.0 (e.g., pyproject.toml and python/CMakeLists.txt). This will lead to inconsistent version reporting (wheel metadata vs die.__version__). Please update all version sources in the repo together or derive the extension version from the project/package version to keep them in sync.

base_path is computed but never used, and the preceding comment says you "can't easily check" it. This is dead code that can be removed to keep the test logic focused and avoid confusing future readers.